Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/internet-drafts/draft-ietf-dns-config-errors-00.txt

Text File | 1993-08-11 | 17KB | 435 lines

INTERNET DRAFT                                            Piet Beertema
Expiration Date: February 13, 1994                        CWI, Amsterdam


        Common DNS Data File Configuration Errors

Status of this Memo

This document is an Internet-Draft.  Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups.  Note that other groups may also distribute working
documents as Internet-Drafts. Internet-Drafts are draft documents valid
for a maximum of six months.  Internet-Drafts may be updated, replaced,
or obsoleted by other documents at any time.  It is not appropriate to
use Internet-Drafts as reference material or to cite them other than as
a ``working draft'' or ``work in progress.''

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.

This document has been edited into the internet-draft format by
Anant Kumar at USC Information Sciences Institute.

This Internet Draft expires February 13, 1994.

Abstract

This memo describes errors often found in DNS data files. It points out
common mistakes system administrators tend to make and why they often
go unnoticed for long periods of time.

Introduction

Due to the lack of extensive documentation and automated tools, DNS
zone files have mostly been configured by system administrators, by
hand. Some of the rules for writing the data files are rather subtle
and a few common mistakes are seen in domains worldwide.

This document is an attempt to list "surprises" that administrators
might find hidden in their zone files. It describes the symptoms of the
malady and prescribes medicine to cure that.

                                [Page 1]

CWI, Amsterdam                            Beertema

1. SOA records

A problem I've found in quite some nameservers is that the various
timers have been set (far) too low. Especially for top level domain
nameservers this causes unnecessary traffic over international and
intercontinental links.

Unfortunately the examples given in the BIND manual, in RFC's and in
some expert documents give those very short timer values, and that's
most likely what people have modeled their SOA records after.

First of all a short explanation of the timers used in the SOA record:

    - Refresh: The SOA record of the primary server is checked
               every "refresh" time by the secondary servers;
               if it has changed, a zone transfer is done.

    - Retry: If a secondary server cannot reach the primary
             server, it tries it again every "retry" time.

    - Expire: If for "expire" time the primary server cannot
          be reached, all information about the zone is
          invalidated on the secondary servers (i.e. they
          are no longer authoritative for that zone).

    - Default TTL: The default TTL value for all records in the
               zone file; a different TTL value may be given
               explicitly in a record when necessary.
               (This timer is named "Minimum" in most examples,
               but that name is highly confusing).

For top level domain servers I would recommend the following values:

      86400 ; Refresh     24 hours
       7200 ; Retry        2 hours
    2592000 ; Expire      30 days
     345600 ; Default TTL  4 days

For other servers I would suggest:

      28800 ; Refresh     8 hours
       7200    ; Retry       2 hours
     604800 ; Expire      7 days
      86400 ; Default TTL 1 day

but here the frequency of changes, the required speed of propagation,
the reachability of the primary server etc. play a role in optimizing
the timer values.

                                [Page 2]

CWI, Amsterdam                            Beertema

2. Glue records

Quite often do people put unnecessary glue (A) records in their zone
files. Even worse is that I've even seen *wrong* glue records for an
external host in a primary zone file! Glue records need only be in a
zone file if the server host is within the zone and there is no A record
for that host elsewhere in the zone file.

A patch for BIND 4.8.3 issued by Andrew Partan of UUnet tackles the
problem of wrong glue records entering secondary servers by masking out
glue records that don't belong to the zone file being pulled in on a
zone transfer. This patch has proved to be very helpful.  A patch to
mask out bad information on outgoing zone transfers should also be
applied, but though currently there is no recommended source for this.


3. "secondary server surprise"

I've seen it happen on various occasions that hosts got bombarded by
nameserver requests without knowing why. On investigation it turned out
then that such a host was supposed to (i.e. the information was in the
root servers) run secondary for some domain (or reverse (in-addr.arpa))
domain, without that host's nameserver manager having been asked or even
been told so! BIND 4.9.x fixed this problem. At the same time the fix
has the disadvantage that it's far less easy to spot this problem.

Note that INTERNIC.NET accepts requests for in-addr.arpa servers WITHOUT
checking if secondary servers have been set up, informed, or asked.


4. "MX records surprise"

In a sense similar to point 3. Sometimes nameserver managers enter MX
records in their zone files that point to external hosts, without first
asking or even informing the systems managers of those external hosts.
This has to be fought out between the nameserver manager and the
systems managers involved. Only as a last resort, if really nothing
helps to get the offending records removed, can the systems manager
turn to the naming authority of the domain above the offending domain
to get the problem sorted out.


5. "Name extension surprise"

Sometimes one encounters weird names, which appear to be an external
name extended with a local domain. This is caused by forgetting to
terminate a name with a dot: names in zone files that don't end with a
dot are always expanded with the name of the current zone (the domain
that the zone file stands for or the last $ORIGIN).

                                [Page 3]

CWI, Amsterdam                            Beertema

Example: zone file for foo.xx:

   pqr        MX 100    relay.yy.
   xyz        MX 100    relay.yy           (no trailing dot!)

When fully written out this stands for:

   pqr.foo.xx.    MX 100    relay.yy.
   xyz.foo.xx.    MX 100    relay.yy.foo.xx.   (name extension!)

6. "Comment surprise"

Inserting comments or comment lines can lead to surprises, since a
comment terminates the currently "active" object (domain, hostname). In
this respect some DNS query tools give a bad example; consider the
(slightly modified) result of this query for a SOA RR:

    @     IN  SOA   sering.cwi.nl.  hostmaster.cwi.nl. (
                        1000406 ;serial
                        86400   ;refresh
                        14400   ;retry
                        2592000 ;expire
                        345600 )        ;minim

If this is taken as an example to base a (new) zone file, one is easily
led to adding other records for the current ("@") object right after
the SOA RR without redefining the object:

          IN  NS      sering.cwi.nl.

instead of

     @    IN  NS      sering.cwi.nl.

However, because the ";minim" comment is outside the brackets of the
SOA RR, it terminates the current ("@") object, so using the first form
to define NS RR's is wrong and leads to errors on (SOA) queries for the
zone. In this example the DNS query tool was wrong by putting the
";minim" comment outside the SOA brackets, since in the original zone
file the comment was within the brackets. However, some documents list
the above output "as is" as an example for constructing zone files.


7. Missing secondary servers

It is required that there be a least 2 nameservers for a domain. For
obvious reasons the nameservers for top level domains need to be very
well reachable from all over the Internet. This implies that there must
be more than just 2 of them; besides, most of the (secondary) servers
should be placed at "strategic" locations, e.g. close to a point where
international and/or intercontinental lines come together.
To keep things manageable, there shouldn't be too many servers for a
domain either.

                                [Page 4]

CWI, Amsterdam                            Beertema

Important aspect in selecting the location of primary and secondary
servers are reliability (network, host) and expedient contacts: in case
of problems, changes/fixes must be carried out quickly.
It should be considered logical that primary servers for European top
level domains should run on a host in Europe. For each top level domain
there should be 2 secondary servers in Europe and 2 in the USA (there
may of course be more on either side).

EUnet has offered to run secondary server for each European top level
domain on mcsun.EU.net.


8. Wildcard MX records

Wildcard MX records should be avoided where possible. They often cause
confusion and errors: especially beginning nameserver managers tend to
overlook the fact that a host/domain listed with ANY type of record in
a zone file is NOT covered by an overall wildcard MX record in that
zone; this goes not only for simple domain/host names, but also for
names that cover one or more domains. Take the following example in
zone foo.bar:

   *        MX 100    mailhost
   pqr        MX 100    mailhost
   abc.def    MX 100    mailhost

This makes pqr.foo.bar, def.foo.bar and abd.def.foo.bar valid domains,
but the wildcard MX record covers NONE of them, nor anything below them.
To cover everything by MX records, the required entries are:

   *        MX 100    mailhost
   pqr        MX 100    mailhost
   *.pqr    MX 100    mailhost
   abc.def    MX 100    mailhost
   *.def    MX 100    mailhost
   *.abc.def    MX 100    mailhost

An overall wildcard MX record is almost never useful.

In particular the zone file of a top level domain should NEVER contain
only an overall wildcard MX record (*.XX). The effect of such a
wildcard MX record can be that mail is unnecessarily sent across
possibly expensive links, only to fail at the destination or gateway
that the record points to. Top level domain zone files should
explicitly list at least all the officially registered primary
subdomains.

Whereas overall wildcard MX records should be avoided, wildcard MX
records can be acceptable as explicit part of subdomains entries,
provided they are allowed under a given subdomain (to be determined by
the naming authority for that domain).

                                [Page 5]

CWI, Amsterdam                            Beertema

Example:

   foo.xx.    MX 100    gateway.xx.
        MX 200    fallback.yy.
   *.foo.xx.    MX 100    gateway.xx.
        MX 200    fallback.yy.


9. Incomplete HINFO records

There appears to be a common misunderstanding that one data field
(usually the second field) in HINFO records is optional. A recent scan
of all reachable nameservers in only one country revealed some 300
incomplete HINFO records. Specifying two data fields in a HINFO record
is mandatory (RFC 1033).

10. Safety measures & specialties

Nameservers and resolvers aren't flawless. Bogus queries should be kept
from being forwarded to the root servers, since they'll only lead to
unnecessary intercontinental traffic. Known bogus queries that can
easily be dealt with locally are queries for 0 and broadcast addresses.
To catch such queries, every nameserver should run primary for the
0.in-addr.arpa and 255.in-addr.arpa zones; the zone files need only
contain a SOA and an NS record.

Also each nameserver should run primary for 0.0.127.in-addr.arpa; that
zone file should contain a SOA and NS record and an entry:

   1    PTR    localhost

People maintaining zone files with the Serial number given in dotted
decimal notation (e.g. when SCCS is used to maintain the files) should
beware of a bug in all BIND versions: if the serial number is in
Release.Version (dotted decimal) notation, then it is virtually
impossible to change to a higher release: because of the wrong way that
notation is turned into an integer, it results in a serial number that
is LOWER than that of the former release.  It can be done, but ONLY if
all secondary servers for the domain are fully restarted (nameserver
killed; secondary file removed; nameserver restarted).

Very old versions of DNS resolver code also have a bug that causes
queries for A records with domain names like "192.16.184.3" to go out.
This happens when users type in IP addresses and the resolver code does
not catch this case before sending out a DNS query. This problem has
been fixed in all resolver implementations known to us but if it still
pops up it is very serious because all those queries will go to the
root servers looking for top level domains like "3" etc. It is strongly
recommended to install BIND 4.8.3 plus all available patches or a later
BIND version to get rid of this problem.

Running secondary nameserver off another secondary nameserver is not a
good idea: it is known to have led to problems like bogus TTL values.

                                [Page 6]

CWI, Amsterdam                            Beertema

This can be caused by older or flawed implementations, but secondary
nameservers in principle should always transfer their zones from the
official primary nameserver.

11. Some general points

The domain name system & nameserver is a purely technical tool, not
meant in any way to exert control or impose politics. The function of
a naming authority is that of a clearing house. Anyone registering a
subdomain under a particular (top level) domain becomes naming authority
and therewith the sole responsible for that subdomain. Requests to enter
MX or NS records concerning such a subdomain therefore always MUST be
honored by the registrar of the next higher domain.

Examples of practices that are not allowed are:

    - imposing specific mail routing (MX records) when registering
      a subdomain.

    - making registration of a subdomain dependent on to the use of
      certain networks or services.

Of course there are obvious cases where a naming authority can refuse
to register a particular subdomain and can require a proposed name to
be changed in order to get it registered (think of DEC trying to
register a domain IBM.XX).

There are also cases were one has to probe the authority of the person:
sending in the application - not every systems manager should be able
to register a domain name for a whole university.  The naming authority
can impose certain extra rules as long as they don't violate or
conflict with the rights and interest of the registrars of subdomains;
a top level domain registrar may e.g. require that there be primary
subdomain "ac" and "co" only and that subdomains be registered under
those primary subdomains.

The naming authority can also interfere in exceptional cases like the
one mentioned in point 4, e.g. by temporarily removing a domain's
entry from the nameserver zone files; this of course should be done
only with extreme care and only as a last resort.

When adding NS records for subdomains, top level domain nameserver
managers should realize that the people setting up the nameserver for a
subdomain often are rather inexperienced and can make mistakes that can
easily lead to the subdomain becoming completely unreachable or that
can cause unnecessary DNS traffic (see point 1). It is therefore highly
recommended that, prior to entering such an NS record, the (top level)
nameserver manager does a couple of sanity checks on the new nameserver
(SOA record & timers OK?, MX records present where needed? No obvious
errors made? Listed secondary servers operational?). Things that cannot
be caught though by such checks are:

    - resolvers set up to use external hosts as nameservers

                                [Page 7]

CWI, Amsterdam                            Beertema

    - nameservers set up to use external hosts as forwarders
      without permission from those hosts.

Care should also be taken when registering 2-letter subdomains.
Although this is allowed, an implication is that abbreviated addressing
(see RFC 822, par. 6.2.2) is not possible in and under that subdomain.
When requested to register such a domain, one should always notify the
people of this consequence. As an example take the name "cs", which is
commonly used for Computer Science departments: it is also the name of
the top level domain for Czecho-Slovakia, so within the domain
cs.foo.bar the [e-mail] is ambiguous in that in can denote both a
user on the host host.cs.foo.bar and a user on the host "host" in
Czecho-Slovakia.

    (This example does not take into account the recent political
    changes in the mentioned country).


Authors' Address:        Editor's Address

Piet Beertema            Anant Kumar
<[e-mail]>        <[e-mail]>

CWI                USC Information Sciences Institute
Kruislan 413            4676 Admiralty Way
NL-1098 SJ Amsterdam        Marina Del Rey CA 90292-6695
The Netherlands

Phone: [phone]        Phone:[phone]
FAX:   [phone]        FAX:  [phone]

This Internet Draft expires February 13, 1994.














                                [Page 8]